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PATENT 

APPARATUS AND METHOD FOR SELECTABLE COMPRESSION 

BACKGROUND OF THE INVENTION 

The present invention relates to communication of data. More particularly, the 
5 present invention relates to methods and apparatus useful in logic devices for adjusting a 
message, attachment, or data file size prior to transmitting. In a specific embodiment, the 
invention provides a unique user interface. 

Multimedia messaging systems that can integrate and deliver voice, email, fax, 
and/or other data are increasingly of interest in environments with installed local area 
10 networks (LANs) that have sufficient bandwidth. One such known system is the 
Xpressions™ unified messaging system, available from Siemens Information and 
Communication Networks, Inc. Common multimedia messaging applications are 
message delivery software applications that can deliver one or more of a variety of 
messages, such as voice mail messages, which are generally stored as WAV, RealAudio, 
15 or other digitally-encoded audio files. Some multimedia messaging applications can also 
deliver other types of digitally encoded files, such as video, still images, facsimiles, or 
executable files. 

Some types of multimedia messages can result in much larger files for 
transmission than typical text messages. Due to the relatively large amount of digital data 

20 generally used to represent voice, for example, a voice mail message of just a minute can 
result in a large file. 

When accessing such a large file for playback over an institutional LAN with 
substantial available bandwidth, minimal delay is incurred. Typical LANs available 
today have maximum design bandwidths of 10Mbps to 100Mbps, with future designs 

25 planned of 1 Gbps. In contrast, remote connection to an institutional server, either from a 
home or while travelling, is often accomplished over a public telephone network using a 
modem (sometimes referred to as POTS, for plain old telephone service). A typical fast 
modem speed or bandwidth is 56Kbps, substantially slower than the speed or bandwidth 
of a typical institutional LAN. Other remote connection methods, such as wireless, 

30 ISDN, or DSL, also can be substantially slower than LAN speeds. As a result, when a 
user attempts to access multimedia emails from home or while travelling, a voice mail 
message of one minute can take several minutes to download. 
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Commonly-owned patent application no. entitled Apparatus and Method 

for Adjustable Data Rate in Multimedia Messaging Systems, filed concurrently herewith, 
discusses prior art and novel methods for addressing the above problem using a second 
connection or channel (such as a second phone line or ISDN channel). While a second 
channel may be available at some locations, such as a home or satellite office, a second 
channel will often not be available at other locations, such as at a hotel room or an 
infrequently used home office. 

Variable compression techniques are known for some audio and video 
transmission technologies. These techniques have generally been applied to continuous- 
stream type of communications, such as a phone call or video transmission. Under these 
techniques, available channel capacity is detected and compression of video or audio is 
adjusted to fit available bandwidth. As known in the art, increased compression is 
generally associated with reduced fidelity in the compressed signal. Such systems are not 
effective for file systems or multimedia message systems, where different compression 
amounts and formats may be appropriate or desired for different file formats or file 
lengths. One example of a variable compression technique for delivering video over a 
network is discussed in U.S. Patent 6,014,694 issued to Aharoni et al. In common with 
some other prior art techniques, this method relies on a specific encoding format that can 
add and drop levels of data based on congestion in the channel. The Aharoni et al. patent 
also discusses measuring channel bandwidth dynamically during transmission and 
adjusting transmission until the sending bandwidth is equal to the receiving bandwidth. 

What is needed is a method or an apparatus that can provide an acceptable means 
for accessing large data files, such as multimedia messages or other compressible data, 
over a reduced bandwidth channel. 

SUMMARY OF THE INVENTION 

The present invention may be understood in the context of a remote user accessing 
a data retrieval application. An important application for the present invention, and an 
independent embodiment, is a multimedia messaging application. Multimedia message 
applications combine access to communications services such as e-mail, voice mail, and 
facsimile in a unified interface. In some cases, these systems can interact with other 
important applications, for example known Enterprise Resource Planning applications. 

However, using the teachings provided herein, it will be understood by those of 
skill in the art, that the methods and apparatus of the present invention could be 
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advantageously used in other situations that allow a user to download separable data 
items or data files, such as file server systems, systems for downloading compressible 
video files, systems for downloading compressible audio files, etc. Therefore, as used in 
the description of the invention below, accessing or downloading a message or message 
5 attachment should be understood to include accessing or downloadable other types of 
data, unless the context requires otherwise. 

In various embodiments of the present invention, a channel speed is known or 
determined and a transmit delay for a particular data file at an original size and one or 
more compression formats is calculated. The channel speed, along with the size of the 
10 data transfer, is used to select an appropriate compression ratio for a message, message 
attachment, or other compressible file. In specific embodiments, a user may indicate 
i n (either at the time of transfer, the time of login, or during client setup) an acceptable delay 

!* 1 or desired compression for a transfer. 

in The invention will be better understood with reference to the following drawings 

j3 15 and detailed descriptions. In different figures, similarly numbered items are intended to 

represent similar functions within the scope of the teachings provided herein. In some of 
Q the drawings and detailed descriptions below, the present invention is described in terms 

^ of the important independent embodiment of a multimedia message system. This should 

^ not be taken to limit the invention, which, using the teachings provided herein, can be 

□ 20 applied to other data accessing situations. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a simple block diagram showing first and second user digital devices 
connectable to a data server over one of two possible channels or connection speeds. 

FIG. 2 is a flowchart illustrating a general method for allowing selectable 
25 transmission of compressed files according to an embodiment of the invention. 

FIG. 3 is a flowchart illustrating a method for presenting various compression 
options to a user. 

FIG. 4 is a simple block diagram showing, according to a specific embodiment of 
the invention, a multimedia message system being accessed by user-side logic over one of 
30 two possible channels or connection speeds. 

FIG. 5 is a block diagram of a specific exemplary system embodying aspects of 
the invention and showing details of specific embodiments of the invention. 



3 



# 



FIG. 6 is a diagram illustrating a portion of an example user interface according to 
specific embodiments of the invention. 

FIG. 7 is a diagram illustrating an example computer device that can embody 
aspects of the present invention. 

DESCRIPTION OF SPECIFIC EMBODIMENTS 



To aid understanding by the reader, the invention will be explained in the context 
of specific computer system configurations. FIG. 1 is a simple block diagram showing 
first and second user digital devices connectable to a data server over one of two possible 
10 channels or connection speeds. Digital devices 100 and 100a can each be any type of 
;3 information appliance, such as, but not limited to, a PC, a laptop computer, a personal 

;S digital assistant (PDA), cellular phone, a television with data access capabilities, etc. 

Device 130 represents any type of device or system or network that provides data to user 
|q information appliances, such as, but not limited to, a file server, an email server, a 

^ 15 multimedia message server, a video server, a voicemail server, etc. As will be understood 
f : from the art and the teachings provided herein, while device 130 is represented in FIG. 1 

j?1 as a single computer, this is but one example for implementing a data service. Data 

3 services may be implemented in a variety of ways, such as but not limited to groups of 

q cooperating computers, a logical process or component of a larger computer, networked 

~ 20 computers, etc. 

Two example data channels are shown for purposes of discussion, a high speed 
connection 110 and a lower speed connection 1 10a. Each of these connections can be any 
kind of data communication channel, such as, but not limited to, a dial-up line over a 
modem, an ISDN connection, a DSL connection, a wireless connection, a cable modem 
25 connection, etc. 

FIG. 1 can be understood to illustrate as an arrangement for downloading various 
data files from a system or network 130 where they reside to a user's digital device 100 or 
1 00a. As will be understood, the situation can arise where the connection speed or 
connection channel (1 10 or 1 10a) through which a user will receive a data file will vary 
30 from time to time. One type of variation can result when a user uses two different 

channels at two different times, for example, a LAN connection at an institutional site and 
a dial-up connection from home. Another type of variation can result from available 
speeds in the same channel at different times. Thus, 110 and 1 10a might represent the 
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same connection that experiences different available channel bandwidths at different 
times, such as networks subject to varying congestion. As will be further understood, this 
variation can occur when a user is using two physically different logic appliances to 
access data (such as a computer system at home and a different on in an office) or when a 
user uses the same appliance, either over different connections (such as a portable 
computer that is carried from home to office or while travelling) or over the same 
connection experience different speeds at different times. 

As described above, a problem may arise for a user accessing a data server when 
invoking transfer of large data files. In an institutional environment, transfer of large data 
files may not be a problem because many institutions have high-speed networks with 
sufficient available bandwidth. When the same user is accessing, for example, large data 
files away from the office, a generally much lower speed connection (e.g. 56 Kbps) may 
be used. Therefore, large files can cause unacceptably long delays. 

FIG. 2 is a flowchart illustrating a general method for allowing selectable 
transmission of compressed files according to an embodiment of the invention. This 
general method is provided to address the problems just discussed in accessing large data 
files over varying speed connections. 

The method may be understood as beginning upon a connection from a user (Step 
Al). This connection may be initiated according to any connection method or login 
procedure known in the art. The transit speed for the channel is determined (Step A2). 
As discussed elsewhere, this determination may be made in a number of ways, such as by 
simply reading characteristics of an incoming connection or sending and timing a test 
message over the connection. In some embodiments, based on an initially determined 
channel speed, a decision is made whether or not compressed data will be provided as a 
transmission option. For higher speed channels, in some embodiments, no compressed 
data will be prepared or transmitted, and the method will default to normal access. 

If compressed files are to be used, a transmit time indication for an original file is 
accessed (Step A3). This transmit time may be determined by multiplying the transit 
speed for the channel and the size of the files. This transmit time indication may be 
computed just for an original file or for original files and compressed versions of those 
files, either from an actual compressed file size or from an estimated compressed file size 
in instances where files are not compressed until a compressed transmission is requested. 
This indication may be a number indicating an estimated delay time or the indication may 



be a more general indication, such as fast, medium and slow, or simply, greater-than- 
threshold or less-than-threshold. 

In conjunction with or after the previous step, a transmit format is determined 
(Step A4). This may be determined without user intervention, by reference to a stored 
5 threshold value. For example, a system parameter may indicate that compressible files 
that would take greater than a particular time interval to download should be transmitted 
in compressed form. This parameter may be adjustable by a user. In alternative 
embodiments, however, a transmit format may be determined by transmitting indications 
for display to a user and waiting to receive a user selection for a file. 
10 Once the transmit method user preference is determined, a compressed file is 

accessed if so indicated (Step A5). In some situations, this compressed file will have 
=o already been prepared and be available as soon as the transmit method is determined. In 

1*2 other embodiments, a compressed file will be prepared only upon determination that a 

^ compressed file is required. Once the appropriate file is available, it is transmitted to the 

q 15 user (Step A6). 

ijy In instances where the previous method is used in a server that will provide 

□ multiple files to a user, the steps of the method may all take place for multiple files as 
?3 soon as a user connects to a system. For example, if a user on a multimedia message 
] Z, system elects to have all current, unread, messages downloaded upon connection, the 

□ 20 method can be performed on multiple messages which will all be downloaded without 

waiting for further user input. In an alternate use, the method could be performed on 
individual files, messages, or attachments when selected by a user for download. 

It will be understood to practitioners in the art and from the teaching provided 
herein that the steps of this method as herein described may be performed exclusively by 
25 a server-side system, such as system 130. Alternatively, the method may be performed 
by a server-side system operating in cooperation with a user-side system. 

It will be further understood to practitioners in the art and from the teaching 
provided herein that the steps of this method, in various embodiments, may be performed 
in different orders. For example, alternative compressed messages may be prepared in 
30 advance for some or all users, before a determination is made regarding transmit time. 

While user logic devices 100 and 100a are illustrated as having a visible display, it 
should be understood that presentation of information and receiving of commands may be 
accomplished via audio input and/or output, such as a computer system customized for 
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use by a visually impaired person or a telephone interface capable of presenting and/or 
accepting audio data. 

FIG. 3 is a flowchart illustrating a method for presenting various compression 
options to a user. It will be understood to practitioners in the art and from the teachings 
5 herein that the steps of this method may be performed exclusively by a client-side system, 
or, alternatively, by client-side system in cooperation with server-side devices. As 
described above, the present invention can be alternatively embodied in a system that 
transmits compressed files without direct user intervention or selection, in which case this 
method will not be performed. 
10 The method may be understood as beginning upon a reception of a list of files 

available for download with compression file options (Step Bl). Logic at the client-side 
]% displays the list and compressed file option data to a user. When large data files are 

= fi present, display to a user may involve at least one file name or identification message 

; saw 

j jj with at least two selectable options indicating two different levels of compression or 

''M 15 indicating two different download times (Step B2). Optionally, there may also be a 
s 3 selectable option that a user can use to indicate that the system should download a 

;3 compressed file or original file according to default rules. Selection by a user is 

; J registered by the client-side logic (Step B3) and is communicated so that the appropriate 

file format may be transmitted (Step B4). 
20 As will be apparent from the teachings herein and the known art, the method as 

described above may include an option that, while accessing a file (or message), allows a 
user to request presentation of a next file without necessarily referring back to the list. 
This request may include an indication to delete a current file or message. 

A number of options are possible for incorporating a next indication into various 
25 embodiments of the invention, as will be apparent from the teachings herein. In one 

embodiment, a request for a next file or message can always go. immediately to the next 
file and download the next file according to default setup parameters. In a further 
embodiment, a request for a next file or message will display specific file download 
options for that file if that file exceeds a threshold size. In a further embodiment, a 
30 request for a next file or message will return the user to the displayed list if that file 

exceeds a threshold size. Specific embodiments can include several of these options and 
allow a user to configure which options are activated. 

The present invention has thus far been described in terms of general methods and 
devices. The previous description is believed to be a full and complete description 
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sufficient to allow an ordinary practitioner in the art to make and use the invention. It 
will be understood to those of skill in the art from the teachings provided herein that the 
described invention can be implemented in a wide variety of specific programming 
environments and logical systems (such as UNIX, Windows, Solaris, Oracle, etc.) using a 
5 wide variety of programming languages (such as SQL, Visual Basic, Pascal, C++, Basic, 
Java, etc.) and wide variety of file formats. 

What follows are descriptions of example systems and methods that embody 
various aspects of the present invention. It is intended, however, that the previous 
discussion and the claims not be limited by examples provided herein. It is further 
10 intended that the attached claims be read broadly in light of the teachings provided herein. 
Where specific examples are described in detail, no inference should be drawn to exclude 
other known examples or examples described briefly from the broad description of the 
invention or the language of the claims. It is therefore intended that the invention not be 
limited except as provided in the attached claims and equivalents thereof. 

15 Multimedia Message Systems 

FIG. 4 is a simple block diagram showing, according to a specific embodiment of 
the invention, a multimedia message system being accessed by user-side logic over one of 
two possible channels or connection speeds. FIG. 4 shows a particularly important 
specific embodiment of the present invention and will be explained by way of a specific 
20 example. It will be apparent to those of skill in the art from the teachings herein that 
many variations in the details of operation of this example lie within the scope of the 
invention. 

In this embodiment, an message server 210 runs primarily in a server process 
space 130a and is accessed by a user logic 310 running on a user information appliance 

25 100. The user logic and server process space communicate over a high-speed connection 
1 10 or an alternate lower-speed connection 1 10a. 

According to this embodiment, a user logs into server 210 from 310, as is known 
in the art. Server 210 sends to 3 10 data that allows 3 10 to display to the user a list of 
available files or messages in accordance with any preset user or system parameters. As 

30 is known in the art, system 310 allows the user to make a selection from messages (or 
other data files) 250 for presentation. As is known in the art for multimedia message 
systems, some messages can themselves be digitally encoded audio data or video data. 
Messages can also have attachments that are either of these or other large data files. An 
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interface module 220 handles communications between the client and server. A 
compression engine 260 handles compression for files or messages where indicated. 

FIG. 5 is a block diagram of a specific exemplary system embodying aspects of 
the invention and showing details of specific embodiments of the invention. This 
exemplary embodiment includes specific mechanisms for determining a channel speed 
and file transfer time and for handling compression that will not be present in all 
embodiments. FIG. 5 shows a representation of a test 140 and reply 150 communicated 
between a user appliance and a server. This figure also shows a list of compression 
formats 250 reported by a client and an applet 240 downloaded from a server to allow a 
client to handle an additional compression format. Interface 220, threshold value 230, 
and timer 240 are shown and operate as described above. The figure shows a 
representation of multimedia email system 210 with individual original messages 252 and 
compressed messages 254. 

Various techniques for determining a channel speed may be used according to the 
invention. The above referenced incorporated, commonly-owned patent application 
discusses alternative systems and methods for determining a channel speed. A channel 
speed may be directly known by a client or server based on how the user initially 
accessed the server or based on monitored user transmissions, and that value can be read 
by the present invention. 

However, many connections will have an effective speed that can vary over time 
or that are not easily read from system parameters. This is especially true for dial-up 
connections, wireless connections, and very heavy-traffic network connections. In this 
case, a mechanism as indicated in FIG. 5 and as discussed in the above-referenced patent 
application, may used to determine channel speed using a test packet. 

According to this embodiment of the invention, to determine channel speed a 
small test data unit (140) is sent between a multimedia messaging server (130) and a 
client (100) over the active channel (1 10 or 1 10a). This test message allows the invention 
to measure an average channel speed, which then may be used to estimate a total transmit 
time for a particular data file or message. The test message may be sent over the channel 
in either direction, and the transit time for the test message may be calculated by either 
the server or the client and then communicated to the other where necessary. Where 100 
and 130 have a common clock between them, the transit time for the test message can be 
determined by sending a single time-stamped test message in one direction. Where there 
is no shared clock or where there is a desire to measure actual round-trip delay, a reply 




data unit (1 50) is sent and the transit time is calculated from the reply receive time. As is 
known in the art, the reply data unit 150 may carry information about the time delay 
between the receipt of 140 and the sending of reply 150 so that allowances can be made 
for processing delays. 

With channel speed determined, transmit time for a particular file is calculated 
from the size of a file or message or attachment. This calculation may be made at either 
the client, or the server, or both. This calculation can be made in a straightforward 
manner, by multiplying the per-byte transmit speed by the number of bytes in a message. 
The calculation may also take into account any overhead latencies or other transmit 
characteristics as known in the art. 

According to the invention, when indicated by the connection or channel speed 
and the message or attachment size, a server makes a compressed version of the data file 
available for transmission. This compressed data file may be prepared by the server by a 
compression engine 260 before a user ever accesses an email account, or the file may be 
compressed on-the-fly as a user logs in or as a user requests download of a particular 
message. Various options may be incorporated in a particular embodiment of the 
invention, or an embodiment of the invention may operate according to a number of 
different options, based on system or user parameters and operating conditions. 

Compression may be controlled by a number of setup parameters. Some of these 
parameters may be established system wide, while others may be established for an 
individual user. As an example, a user may set a parameter to indicate that the user never 
or rarely accesses e-mail outside the office. For that user, the email system may not 
prepare any compressed messages until the user first logs on from a slow connection. A 
different user may travel only rarely, but for extended periods. This user may set a 
parameter to compress all messages exceeding the threshold while travelling and reset the 
parameter to compress no messages when the user returns to the office. A third user may 
daily access email from both home and work. This user may set up a parameter asking 
the system to always prepare compressed files for messages or attachments that will have 
more than a threshold transmit time at the slowest encountered setting. Other parameters 
according to the invention may indicate what decoding formats can be handled by the 
client and therefore allow a server to determine desired compression formats. 

A system according to a specific embodiment of the invention can use artificial 
intelligence type analysis in media server 210 or a cooperating software component to 
determine when or how to compress messages based for example on different user's 
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usage patterns and based on available system resources. In such a system, for example, 
compression may be performed only for users that have a history of logging in from 
lower-speed lines. The system may query a user the first time the user accesses email 
over a low-speed connection as to whether the user will likely do so again, with a series 
5 of options or questions. An example of one such option, which might be appropriately 
selected by a user while travelling, would be: "Please prepare compressed files for me 
until the next time I log in from a high-speed connection." An example of a different 
option, which might be appropriately selected by a user logging in very infrequently from 
a low-speed connection, would be: "Do not prepare compressed files for me until I log on 
10 from a low-speed connection." 

An intelligent component of the system might also defer performing any pre- 
^ compression while the computer system is experiencing heavy use or might defer pre- 

5 ; 

SW 

fs compression or delete compressed files when available storage space is low. 

^ According to specific embodiments of the present invention, a server according to 

2 15 the invention can perform compression according to a variety of compression algorithms. 
B The server maintains information about which algorithms are available at a particular 

U client and may learn from the client from time to time which algorithms are available at 

the client or desired by the user such as via a compression format list 250. According to a 
*k further embodiment, a server can in some instances download to the client an application 

i 20 or applet 240 to enable the client to handle a particular type of compressed file. 

It should be understood that a data file or a message may be encoded into a variety 
of compression formats. Some of these formats, such as JPEG, MPEG, ZIP, or 
RealAudio have built-in variable compression. The present invention may be used with 
various audio formats, such as wave audio, G.723, RealAudio, GSM. The present 
25 invention may be used with various image formats, such as JPEG, GIF, TIFF, BMP, XIF, 
or PDF. The present invention may be used with various video formats, such as MPEG, 
AVI, etc. The present invention may also be used with compressed file formats, such as 
ZIP or Stufflt 

The present invention may be embodied into a data access system with a number 
30 of different options for user interaction, compression selection, and data transfer. 

In one embodiment, the invention may operate for the most part transparently to a 
user. A data server and user logic, according to this embodiment, will determine a 
transmission speed for a connection, as discussed above, and will transmit compressed 
files when appropriate. A user may notice some reduced audio or video fidelity when 
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connecting over a lower speed connection, and may adjust some overall operating 
parameters, but otherwise will interact with user logic over a lower speed connection just 
as he does over a higher speed connection. From the user's perspective, the display may 
look like one of any known email clients or data access clients. 

In an alternative embodiment, the present invention will display for a user options 
to download uncompressed or compressed data for files. FIG. 6 is a diagram illustrating a 
portion of an example user interface according to specific embodiments of the invention. 
In the example, a user display (400), displays a list of available files or messages, with 
identification data for messages (402), such as, but not limited to, sender, date or subject. 
As shown in this example, for some messages, the invention lists a download time as an 
uncompressed file (410) or as a compressed file (412) in one or two alternative formats. 
For some types of files, either no compressed format or less than a full number of 
compressed formats may be available. In this example, each download time is 
underlined, indicating that it is a clickable link. A user, presented with the interface, can 
for any message click on a preferred compression size or transmit time. Thus a user, 
while accessing a multi-media message system, can select, for each message, an 
appropriate compression ratio. For some messages, depending on length and the source 
of the message, a user may determine that maximum compression is likely to give 
adequate performance. While for other messages, a user may choose less compression or 
no compression. For example, a user may have one co-worker who speaks slowly and 
deliberately, and a user may chose high compression for messages from that co-worker. 
Another co-worker may speak very rapidly, and for that co-worker, the user may select 
low compression or no compression. A user may also initially select high compression 
for a file, and if the fidelity is not adequate, the user may then download a less 
compressed version of the file. 

Other arrangements of the user interface of FIG. 6 are possible. For example, 
actual times may not be displayed and buttons may simply indicate compressed or non- 
compressed downloads. The interface may also include an option that allows a user to 
select a default download for a particular message, such as selecting the subject line, 
which will indicate to the invention that the invention should pick an appropriate 
compression for that message based on preset parameters. 

Note that the user interface shown in FIG. 6 shows a number of different file types 
with different options. Two types of audio file are indicated, a Wave file used to encode 
internal voice mails, and an "audio" format, used for external voice mails. In this 
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example, no compression options are provided for files that will take a short time to 
download. A PDF file attachment is listed in the example. In this particular embodiment, 
only a high compression version is shown for this essentially text file, because a 
decompressed text or executable file must generally be an exact copy of the original file, 
so only the highest compression that can be losslessly decompressed is used. However, 
some "text" files may contain embedded graphical, audio, or video elements and in 
specific embodiments of the invention these may be variably compressed. 

Embodiment in a Programmed Information Appliance 

FIG. 7 is a diagram illustrating an example computer device that can embody 
aspects of the present invention. The invention can be implemented in hardware and/or 
software. In some embodiments of the invention, different aspects of the invention can be 
implemented in either client-side logic or a server-side logic. As will be understood in 
the art, the invention or components thereof may be embodied in a fixed media (and/or 
transmissible) program component containing logic instructions and/or data that when 
loaded into an appropriately configured computing device cause that device to perform 
according to the invention. 

FIG. 7 shows an information appliance (or digital device) 700 that may be 
understood as a logical apparatus that can read instructions from media 717 and/or 
network port 719. Apparatus 700 can thereafter use those instructions to direct server or 
client logic, as understood in the art, to embody aspects of the invention. One type of 
logical apparatus that may embody the invention is a computer system as illustrated in 
700, containing CPU 707, optional input devices 709 and 711, disk drives 715 and 
optional monitor 705. Fixed media 717 may be used to program such a system and may 
represent a disk-type optical or magnetic media, magnetic tape, solid state memory, etc.. 
The invention may be embodied in whole or in part as software recorded on this fixed 
media. Communication port 719 may also be used to initially receive instructions that are 
used to program such a system and may represent any type of communication connection. 

The invention also may be embodied in whole or in part within the circuitry of an 
application specific integrated circuit (ASIC) or a programmable logic device (PLD). In 
such a case, the invention may be embodied in a computer understandable descriptor 
language which may be used to create an ASIC or PLD that operates as herein described. 
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The invention has now been described with reference to specific embodiments. 
Other embodiments will be apparent to those of skill in the art. In particular, a user 
digital information appliance has generally been illustrated as a personal computer. 
However, the digital computing device is meant to be any device for interacting with a 
remote data application, and could include such devices as a digitally enabled television, 
cell phone, personal digital assistant, etc. 

Also, channels have been described primarily as traditional phone lines or network 
connections, with the appropriate corresponding hardware. However, channels are meant 
to be any channels capable of carrying data, including wireless channels, optical channels, 
and electrical channels. 

Furthermore, while the invention has in some instances been described in terms of 
client/server application environments, this is not intended to limit the invention to only 
those logic environments described as client/server. As used herein, "client" is intended 
to be understood broadly to comprise any logic used to access data from a remote system 
and "server" is intended to be understood broadly to comprise any logic used to provide 
data to a remote system. 

It is understood that the examples and embodiments described herein are for 
illustrative purposes only and that various modifications or changes in light thereof will 
be suggested by the teachings herein to persons skilled in the art and are to be included 
within the spirit and purview of this application and scope of the claims. All publications, 
patents, and patent applications cited herein are hereby incorporated by reference in their 
entirety for all purposes. 
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